系列：30 天用 Google AI 打造臺灣防災速報 App（Day 30/30）

連載從 9/15 開始，今天是最後一篇。先說現況：App 還沒上架，Google Play 封閉測試（上架前只給受邀測試者安裝的階段）尚未開放，iOS 的 TestFlight 外部測試還在等 Apple 審查，進度見文末「下一步」。

30 天做了什麼

• 第一週（Day 1–7）資料。 接上國家災害防救科技中心的民生示警和中央氣象署的地震報告。示警編號（id）會重複，資料一筆時回傳單一物件、多筆時回傳陣列，都是這週遇到的問題。
• 第二週（Day 8–14）AI。 速報摘要、警報分級、Function Calling（讓模型自己呼叫查詢程式）問答、知識庫檢索，以及多語翻譯。
• 第三週（Day 15–21）後端上線、做出 App。 Firestore（雲端資料庫）加 Cloud Functions（雲端函式），每 10 分鐘同步示警。Google Stitch 產生畫面設計，Flutter 框架用同一個專案建置 Android、iOS 和網頁版。使用者的提問被判斷為危機時，回答先給求助專線。
• 第四週（Day 22–29）收尾。 兩篇地震科普、歷史地震地圖、Android 推播、不讓 AI 合併警報的理由、評測、費用與資安，最後是 Day 29 的成果展示。

現在的防災速報（英文 Taiwan Disaster Alerts）有四個分頁：

• 示警：各機關發布、仍生效的示警，分極重大、重大、警戒、資訊四級，可以依分類和縣市篩選。較長的示警附 AI 摘要（沒有摘要時顯示原文），發布單位原文收在下面。
• 地震：中央氣象署的地震報告，每 2 分鐘同步。另有歷史地震地圖，標出美國地質調查所（USGS）地震目錄中，1996–2026 年臺灣周邊規模 4.5 以上的 2,011 起地震。
• 災害問答：Gemini 回答時，依據知識庫裡的官方資料，或即時查詢生效中的示警和近期地震；依官方資料的回答會附上出處。問到地震預測時，給固定的回答；使用者的提問被判斷為危機時，回答最上方先出現求助專線。
• 緊急協助：119、110 和心理支持專線，點了直接撥號；另有防災準備頁（避難包清單、災害應變）。

Android 推播 10/7 起正式送出，只推極重大和官方等級的重大；官方沒給等級、改由 AI 判斷等級的示警，以及地震報告，都不推。介面有中文、英文、日文。不用註冊、不取得定位、沒有廣告。App 由個人開發，不是政府機關的服務，與任何政府機關無關。

想看實際操作的樣子，可以看這支介紹影片：https://youtu.be/lj3BDv939e4

和開賽時規劃不一樣的地方

連載裡列過路線圖、工具和資料規劃，實作後有幾項改了，這裡照實際做出來的寫：

• 推播：路線圖寫 Android 和 iOS 都做。現在正式送出的只有 Android；iOS 只在 iPhone 接電腦的除錯版收到過測試推播。
• 發布：路線圖寫第四週雙平台發布。目前 Google Play 封閉測試還沒開放，iOS 的 TestFlight 外部測試還在等 Apple 審查（見「下一步」）。
• 英文名稱：Day 1 寫的英文名是 AI Watchtower。App 的英文名後來定為 Taiwan Disaster Alerts，AI Watchtower 留作專案名稱。
• 代理（Agent，能自己決定步驟、呼叫工具的 AI 程式）：Day 1、Day 3 規劃做一個代理，後來也考慮讓它把多則示警合成一則通知。最後決定不做（理由見下方「不讓 AI 合併警報」），所以 Day 3 說要回頭評估的 Gemini Enterprise Agent Platform 也沒有用上。
• 問答工具：Day 3 預計三個工具，問答的 Function Calling 實際只有兩個：查生效中的示警、查近期地震。另外寫好了查雨量預報的查詢，但資料的使用條款不允許公開發布，所以沒有接進問答（Day 26）。
• 氣象署資料：Day 6、Day 7 規劃每一輪另外下載氣象署的天氣特報，地震報告只在出現地震示警時才查。最後沒有接天氣特報，示警都取自國家災害防救科技中心的彙整；地震報告改成每 2 分鐘固定同步（Day 16）。
• 網頁版：原本只打算做產品介紹網站。後來網頁版和手機版用同一個 Flutter 專案建置，功能大致相同，只是沒有推播。
• 日本防災資料：Day 2 說要收錄做參考，沒有做，先把臺灣官方資料做好（Day 11、Day 14）。

留下來的做法

官方等級優先，AI 只補空缺。 示警電文（CAP，官方示警的共通格式）裡有官方給的嚴重度時，就照官方等級，分級不交給模型。官方沒給等級時，才讓 Gemini 依分級表判斷，而且最高只能給到重大；極重大一定要有官方依據。AI 補判的等級在 App 裡照樣顯示，但不推播（Day 9、Day 21、Day 25）。

模型看得到的文字，它會當成該寫的內容。 規則裡出現「無海嘯威脅」，沒提到海嘯的地震報告也被寫上這句（Day 8）。術語表有「中央氣象署」，原文沒提到氣象署，譯文結尾卻多了一句「中央氣象署發布」（Day 13）。和這則電文無關的固定文字不放進提示詞，求助文字這類固定內容由程式加上（Day 14、Day 20）。

下載與整理不交給 AI。 抓資料、去除重複、分類都用一般程式處理，Gemini 只讀整理好的事件（Day 7）。同一個 id 底下可能有不同等級；照「同 id 取最新」，土石流的紅色警戒（較嚴重）會被較新的黃色警戒蓋掉（Day 5）；某則示警這次下載沒出現，也不代表已經結束（Day 16）。

「沒有資料」不等於「沒有示警」。 查不到就說查不到，不說成當地沒有示警（Day 10）。離線或只有舊快取時，首頁不顯示「目前沒有生效中的示警」（Day 19）。

不讓 AI 合併警報。 把多則示警合成一則通知，模型得推論示警之間的因果，還可能寫出沒有任何機關發布過的文字（Day 26）。推播文字只來自單一示警。通知太多的問題，用去除重複和冷卻時間處理：同一則示警的後續更新，同一個縣市只推一次；同縣市、同等級、同類別 30 分鐘內只推第一則，極重大不受限（Day 25）。想看全貌，由使用者在問答裡主動問。

評測先看漏報。 漏報（該升級卻沒升級，推播就發不出去）比誤報（不該升級卻升級）嚴重，所以不用準確率這類單一總分：先看漏報底線，再看誤報。考卷分四組：「正常格式」「髒資料」「刻意刁鑽」「像警報但不是」，各組分開報數字。摘要由另一個 AI 模型打分數，它也會判錯，所以被判沒過的題目要人工複核；最後再用新進電文驗一次（Day 27）。

擋掉沒通過驗證的請求前，先確認權杖會換新。 App Check 用來確認請求真的來自防災速報 App，App 會帶一張有期限的驗證憑證（權杖）。權杖到期後沒有自動換新，過一段時間請求就被判無效。修法是打開 SDK（軟體開發套件）的自動換新，另外在到期前主動換新、讓 Firestore 重新連線。Firestore 開始拒絕沒通過驗證的請求後 24 小時，App 的請求被拒 0%，被拒的全是開發測試和後端自測（Day 28）。

AI 和示警同步分開。 下載示警和 AI 加值（摘要、翻譯）拆成兩支函式（Day 16）。9/26 Gemini 額度不足，AI 停了約 6 小時，示警照常同步，只是少了 AI 摘要和翻譯（Day 21）。

估費用不能只算模型呼叫。 Day 14 只算了 Gemini 的呼叫，資料庫讀寫留到上線後核對。第一版每 10 分鐘一輪，每輪把約 800 則已結束的示警重寫一次，照這個寫法一天約寫入 12 萬次；改成只寫有變化的文件後，每天只剩幾百次（Day 16、Day 21）。雲端費用是正式上架前每月約 2–3 美元。

還沒做完的事

• iOS：iPhone 接電腦的除錯版已收到測試推播；TestFlight 測試版也在 iPhone 上跑過，但還沒用它收過推播。TestFlight 外部測試已送 Apple 審查，App Store 審查還沒送，一般使用者裝不到。
• 網頁版推播：Android 版的推播依縣市、等級和語言分成不同主題（推播服務用來分組的名單）發送，裝置訂閱了主題才收得到。Flutter 的 Firebase 套件在網頁上不能直接訂閱主題，要另外寫後端服務代替，這次沒做（Day 25）。
• 摘要的縣市區間：縣市很多的電文，摘要可能被壓成「桃園市至屏東縣」這種區間，等於多涵蓋原文沒有的縣市。評測程式的縣市檢查只在原文 3 個縣市以內時套用，抓不到這種錯；正式流程也還沒有這項檢查，列為待修（Day 27）。
• 示警的新舊版本：CAP 電文的更新鏈（references 欄位，標明這則取代哪一則）目前只用在推播去除重複。示警列表還沒用它，同一事件的新舊版本仍可能同時出現（Day 5、Day 16）。
• 危機機制的專業審閱：危機判斷和求助文字，還沒有經過心理專業人員審閱（Day 20）。
• 知識庫檢索的門檻：相似度門檻（問題和知識庫段落要多接近，才拿來回答）0.75 是 Day 12 用九個問題定的。之後補知識庫內容時，用更多問題檢查過沒有退步，門檻維持 0.75；但還沒有像 Day 27 那樣出一份分組的考卷重新驗證。
• 防災準備頁的急救知識：大部分內容寫好了，CPR 的細節還待補；要等醫療專業人員確認後才開放，目前在 App 裡隱藏。
• 在地氣象觀測：Day 6 提過用氣象署自動氣象站的觀測做在地資訊，沒有做。

下一步

最近的一步是上架 Google Play。上架前要有測試者連續加入封閉測試 14 天，如果你願意幫忙，請用 Android 手機加入這個群組，封閉測試開放時會收到通知：

https://groups.google.com/g/watchtower-lab-testers

測試時覺得使用上有任何問題或異常情況發生，可以在 Google Play 的測試版頁面留意見；回答不對，可以用每則回答下方的「回報這則回答」按鈕告訴我。加入群組時我會看到你的 Google 帳號名稱和 email，只用來管理測試名單，正式上架後30天內刪除群組。Google Play 會依群組名單開放你的帳號安裝測試版。

Google Play 開發者帳號 10/13 通過驗證，App 已在 Google Play 後台建好，正在內部測試；封閉測試要送審、通過後才會開放。封閉測試跑完、通過審查，才能正式上架。時間要看 Google 的審查，還沒有確定的日期。

iOS 版已在 iPhone 實機測過推播（除錯版）和 TestFlight 測試版，TestFlight 外部測試已送 Apple 審查，通過後再送 App Store 審查；在那之前一般使用者裝不到。用 iPhone 的話，可以先用網頁版：https://ai-watchtower-tw.web.app

今日小結

• 30 天做出防災速報：示警、地震、災害問答、緊急協助四個分頁，Android 推播 10/7 起正式送出。
• 和開賽時規劃不同的地方：推播只有 Android、還沒雙平台發布、沒有做代理、網頁版做成和手機版功能大致相同的 App。
• 留下來的做法：官方等級優先、AI 只補空缺；下載與整理不交給 AI；推播文字只來自單一示警，不讓 AI 合併警報。
• 還沒做完：iOS 開放測試與 App Store 送審、網頁版推播、摘要的縣市區間、示警的新舊版本、危機機制的專業審閱、知識庫門檻的正式評測、急救知識、在地氣象觀測。
• 下一步是上架 Google Play：封閉測試準備送審，開放時需要 Android 測試者。

全系列到這裡結束，謝謝看到最後的讀者。